Update all internal users of gtk_dialog_get_action_area

Some of these should be revisited and fixed. For now,
just avoid the deprecation warnings.

dialog: Mark gtk_dialog_get_action_area as deprecated

Direct access to the action area by applications makes it much more
difficult to make changes to GtkDialog. Therefore, deprecate this
function.

demo: Add new button box layouts

This adds a test case for the new expand layout.

https://bugzilla.gnome.org/show_bug.cgi?id=720059

button box: Set linked style for extend

This is needed for proper styling of the new extend-placement
in button boxes.

Add an expand button box type

https://bugzilla.gnome.org/show_bug.cgi?id=720059

window: Allow unsetting custom titlebar

https://bugzilla.gnome.org/show_bug.cgi?id=720059

headerbar: Set a minimum size for the title

https://bugzilla.gnome.org/show_bug.cgi?id=720059

Use gtk_window_close for gtk_dialog_close

We manually synthethized the delete event, but now we have the
corresponding method in GtkWindow

widget: Add deprecation annotations for {get,set}_margin_{left,right}

Fallout from 9921bec63a3e67e2c2e38ca734590909a9f734b5

[l10n] Updated Estonian translation

Updated Spanish translation

Updated POTFILES.skip

Bump version

Always return FALSE from the notebook leave_notify handler

As discussed on IRC with Benjamin, this should not make much
difference in practice, but it is more correct

Readd line removed by mistake in the previous commit

Prelight notebook tab

Set the prelight state when hovering a notebook tab with the mouse.

https://bugzilla.gnome.org/show_bug.cgi?id=711233

Make the action bar reftest reliable

Updates

Update expected output for tree.ui

Now that the utf8 actually appears...

Run accessibility tests in en_US.utf8

Previously, we were just using the C locale, which breaks
some of our fancy utf8 output for checkmarks and so on.

GtkApplicationWindow: give up on handling dispose

Stop trying to deal with "theoretical possibilities".

We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.

The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead.  The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.

We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.

https://bugzilla.gnome.org/show_bug.cgi?id=722189

treemodelfilter: Fix typo in API docs

Add some treeview a11y tests

A11y: Fix text functions for table cells

Keep the PangoLayout around, and refresh in update_cache.

https://bugzilla.gnome.org/show_bug.cgi?id=707729

window: add an is-maximized property to GtkWindow

With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.

https://bugzilla.gnome.org/show_bug.cgi?id=698786

Don't implement popup_menu in GtkWindow

This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.

https://bugzilla.gnome.org/show_bug.cgi?id=722106

Fix memory leak in GtkTreeViewAccessible

https://bugzilla.gnome.org/show_bug.cgi?id=722030

Add separator before "Always on Top" to the CSD window

https://bugzilla.gnome.org/show_bug.cgi?id=722076

Fix a memory leak

https://bugzilla.gnome.org/show_bug.cgi?id=722029

gdk: Don't leak GValue when xsetting is unknown

https://bugzilla.gnome.org/show_bug.cgi?id=722070

reftests: Add reftest for 0px border fix

https://bugzilla.gnome.org/show_bug.cgi?id=721800

themingengine: Don't draw 0px borders

Theming code gets confused when computing the spacing for 0px wide dots
and then divides by 0. And then cairo complains and stops drawing
anything forever out of spite and then we end up with a single color
screen.

https://bugzilla.gnome.org/show_bug.cgi?id=721800

Updated Spanish translation

build/: Rename a Shared MSVC NMake Makefile

Rename testsrules_msvc.mak to detectenv_msvc.mak and remove some package-
specific stuff from it, to reflect on the nature that this NMake Makefile
is shared.

MSVC Builds: Rework Introspection Build

The current approach of building the introspection files for GTK works, but
is often cumbersome as one needs to set many environmental variables before
launching a solution file, which runs a Windows batch script to generate
the .gir/.typelib files. It was also possible to hand-run the batch script
from the Visual Studio command prompt, but even more environmental
variables need to be set.

This changes the approach to build the introspection files using an NMake
Makefile (but elimating from the Visual Studio Project Files the part to
build the introspection files) to:
-Make it clearer to the person building the introspection files what
 environmental variables are needed, specifically for PKG_CONFIG_PATH and
 MINGWDIR and CFG (formerly CONF). Setting stuff like VSVER, PLAT and BASEDIR
 is no longer required, which was a bit clunky.

-Allows some more easier flexibility on the build of the intropsection files.

Updated Greek translation

Updated Hebrew translation

Update gtk-install.*props

Make sure the needed public headers for GTK master is "installed", and re-
order some items so that it is easier when the headers lists are
automatically acquired from the various Makefile.am's.

build/win32/vs9/Makefile: Fix typo

Add move and resize to the csd window menu

With the previous commit, these operations can be implemented
now.

X11: Support keyboard-initiated move and resize operations

The EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.

Redo csd window-dragging

The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.

This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.

gtk-demo: Use primary-toolbar style in the application example

Adwaita correctly restricts window-dragging to primary toolbars,
Mark our toolbar as primary to test this.

Some struct repacking

Save a few bytes here and there.

Updated Galician translations

Changed obsolete FSF portal addresses to web address
Fixed https://bugzilla.gnome.org/show_bug.cgi?id=721530

gtk3-demo: avoid a resizing problem

Two changes that sneaked in during the GtkApplication port
made it so that the window would not let you shrink it again
after you've made it larger. This also yielded very surprising
results when unmaximizing the window: it would come back to
have a minimum width slightly larger than the screen, making
maximization fail from then on.

Update Chinese simplified translation

gtkwindow: Rename get_decoration_size => get_shadow_width

gtkapplication: add missing annotation for set_accels_for_action

README: Add note about gtk_text_view_add_child_in_window changes

GtkTextView: Fix scrolling of added children

The behaviour of gtk_text_view_add_child_in_window() used to be
quite broken. It scrolled with the window during scrolling, then
jumped to the absolute position when the widget resized. Furthermore,
in 3.10 we broke the first feature, making it always be fixed.

The "proper" way to handle this is to always follow scrolling. This
is what the only user so far (gedit) wants, and if you want some
kind of overlay you should use GtkOverlay instead.

So, this changes the behaviour to something that is internally consistent
and works. I.e. all added widgets scroll with the textview as needed.

https://bugzilla.gnome.org/show_bug.cgi?id=711826

testtextview: Add test for gtk_text_view_add_child_in_window

https://bugzilla.gnome.org/show_bug.cgi?id=711826

[l10n] Updated Italian translation.

x11: Add/Fix '(type *)' g-i annotations

Simplify GtkActionHelper

Now that the last GMenuModel-based user of GtkActionHelper is gone, we
can substantially simplify it.

https://bugzilla.gnome.org/show_bug.cgi?id=721836

Use GtkMenuTracker for Quartz backend.

https://bugzilla.gnome.org/show_bug.cgi?id=710351

Move get_key_equivalent() to gdk quartz utils.

https://bugzilla.gnome.org/show_bug.cgi?id=710351

Updated German translation

GtkMenuTracker: fix hidden-when='' vs. separators

Ensure that adding hidden-when='' to a menu item does not produce an
extra separator item as a side effect.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

bloatpad: test hidden-when=''

Cook up some silly cases to test out the hidden-when='' attribute.

 - make sure hidden-when='action-missing' shows/hides items based on
   actions being created and destroyed

 - make sure hidden-when='action-disabled' shows/hides items based on
   actions being enabled and disabled

 - make sure hidden-when='action-missing' doesn't hide items when the
   action is merely disabled

https://bugzilla.gnome.org/show_bug.cgi?id=688421

GtkMenuTracker: remove hidden items from the menu

Modify the tracker so that it manages the visibility of
GtkMenuTrackerItem by issuing insert and remove callbacks to the
user of the tracker.

This works by treating the GtkMenuTrackerItem as a virtual section which
contains 1 item when the item is visible and 0 items when it is hidden.

For efficiency reasons, we only employ this trick in the case that the
item has a hidden-when='' attribute set on it.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

GtkMenuTrackerItem: add an internal 'visible' flag

Add an internal API for checking if a GtkMenuTrackerItem is visible,
along with a signal for reporting changes in that flag.  The item will
become invisible in situations according to the new hidden-when=''
attribute, which can be set to 'action-disabled' or 'action-missing'.

This new flag doesn't actually do anything yet, and none of the
consumers of GtkMenuTracker do anything with it (nor should they).  A
followup patch will address the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

GtkMenuTracker: rework action removal a bit

Refactor the code in the action observer remove function in order to
make way for the (efficient) handling of hiding of the item in the case
that hidden-when='' is given.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

GtkMenuTrackerItem: small logic tweak

Strictly speaking, can_activate should always be set back to FALSE when
the action disappears from the muxer (since we can't activate it
anymore) but we forgot to do that.

This 'bug' could never cause a problem because 'can_activate' is never
directly queried for anything at all and the item would get marked
insensitive anyway.  As soon as the action was re-added, can_activate
would be recalculated based on the new action before anything else could
happen.

All the same, this should be cleared here.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

GtkMenuTracker: cache result of hash lookup

Remove a hash lookup from the separator sync logic (which is run every
time we change a menu).  Instead, we do the lookup when creating the
section and cache the result.

This refactor will also help us in a future commit to add support for
hiding menu items based on missing actions.

https://bugzilla.gnome.org/show_bug.cgi?id=688421

colorbutton: fix crash when destroying the colorbutton from the color-set signal

Updated Spanish translation

PixelCache: Ensure clean cairo_t state in draw

This adds save/restore calls to the clear-to-transparent call in
the pixel cache, to avoid changing the default color of the
cairo_t. It also removes a call set_operator call that is no longer
necessary (it was trying to manually restore the state).

https://bugzilla.gnome.org/show_bug.cgi?id=721480

fix prototypes of signal callbacks in the test suite

The signal callbacks are defined to take pointers as their arguments, but the
callbacks found in testsuite/gtk/builder.c are passing a GParamSpec by value
as the second argument.  This confuses and angers the compiler on ppc64el,
resulting in segfaults after return from the function due to stack-smashing
by the (completely-unused) argument.

https://bugzilla.gnome.org/show_bug.cgi?id=721700

Add icon menu to bloatpad.

https://bugzilla.gnome.org/show_bug.cgi?id=710351

GtkIconInfo: add gtk_icon_info_is_symbolic()

https://bugzilla.gnome.org/show_bug.cgi?id=710351

gtkapplication-quartz: clean up inhibit code

When testing with bloatpad, the existing inhibit code seems not to be
working at all.  Replace it with a cleaner and simpler version that
works.

https://bugzilla.gnome.org/show_bug.cgi?id=720551

app window: test actiongroup across destroy

Make sure that we don't violate the interface contract of GActionGroup
just because gtk_widget_destroy() was called.

https://bugzilla.gnome.org/show_bug.cgi?id=710351

Fix GtkApplicationWindow action group implementation

GtkApplicationWindow frees its internal action group on dispose for the
usual reasons: to avoid the possibility of reference cycles caused by
actions referring back to the window again.

Unfortunately, if it happens to be inside of a GtkActionMuxer at the
time that it is disposed, it will (eventually) be removed from the muxer
after it has been disposed.  Removing an action group from a muxer
involves a call to g_action_group_list_actions() which will crash
because the internal action group to which we normally delegate the call
has been freed.

A future patch that reworks the quartz menu code will introduce a use of
GtkActionMuxer in a way that causes exactly this problem.

We can guard against the problem in a number of ways.

First, we can avoid the entire situation by ensuring that we are removed
from the muxer before we destroy the action group.  To this end, we
delay destruction of the action group until after the chain-up to the
dispose of GtkWindow (which is where the window is removed from the
GtkApplication).

Secondly, we can add checks to each of our GActionGroup and GActionMap
implementation functions to check that the internal action group is
still alive before we attempt to delegate to it.

We have to be careful, though: because our _list_actions() call will
suddenly be returning an empty list, people watching the group from
outside will have expected to see "action-removed" calls for the
now-missing items.  Make sure we send those. but only if someone is
watching.

https://bugzilla.gnome.org/show_bug.cgi?id=710351

Add a reftest for GtkActionBar child ordering

This shows that GtkActionBar and GtkBox treat pack-start/-end
the same.

Updated POTFILES.in

GtkActionBar: Just leave the center widget as NULL, initially

No need to construct a box that gets thrown away later.
Plus, this fixes the defaultvalue test for GtkActionBar.

Release-note the headerbar child order change

Make testsplitheaders more robust

Same empty string issue that I fixed in GtkHeaderBar a few days
ago.

Updated Hungarian properties translation

Add an action bar test

https://bugzilla.gnome.org/show_bug.cgi?id=721665

Fix order of pack-end widgets

https://bugzilla.gnome.org/show_bug.cgi?id=721665

widget-factory: add actionbar

https://bugzilla.gnome.org/show_bug.cgi?id=721665

tests: use actionbar in headerbar test

This is a great example of where headerbar should not be used.

https://bugzilla.gnome.org/show_bug.cgi?id=721665

Add GtkActionBar

A widget intended to offer contextual actions for a given view.
It allows packing children into the start or end as well as offering
a single centered child box.

https://bugzilla.gnome.org/show_bug.cgi?id=721665

Updated Spanish translation

Updated Spanish translation

GtkHeaderBar: Fix positioning of pack-end widgets

This makes the positioning of pack-start and pack-end
widgets symmetric.

Make testtitlebar more versatile

Test adding multiple custom widgets at each end. This exposes
that we're doing it wrong - the pack-end widgets are ordered
in the wrong way.

Update Kazakh translation

Avoid compiler warnings

filechooser: Document the settings XML

Be more careful when parsing gtk-decoration-layout

When the string is empty, breaking it at : will not give
us two tokens, and we were parsing garbage, leading to crash.
https://bugzilla.gnome.org/show_bug.cgi?id=721635

quartz: implement gdk_window_set_shadow_width()

Use the information to allow dragging windows all the way to the top of
the screen (ie: allow the top shadow to go under the menubar).

https://bugzilla.gnome.org/show_bug.cgi?id=720374

quartz: fix manual window move

We need to have gdk skip standard processing of events when we are in
manual move in addition to manual resize.

https://bugzilla.gnome.org/show_bug.cgi?id=720357

tests: add menu alignments to the menubutton test

https://bugzilla.gnome.org/show_bug.cgi?id=720939

tests: add some space to menubutton test

https://bugzilla.gnome.org/show_bug.cgi?id=720939

Fix positioning of up menu button popup

Use the menu allocation instead of the request size.

https://bugzilla.gnome.org/show_bug.cgi?id=720939

bloatpad: fix the action associated with the notification

Notifications can only be associated with application actions,
but clear is a window action. Introduce a "clear-all" action
that forwards to clear on all windows.

https://bugzilla.gnome.org/show_bug.cgi?id=721633